Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@__tests__/components/meme-calendar/meme-calendar.helpers.timezone.test.ts`:
- Around line 34-36: The afterEach cleanup is restoring process.env.TZ by
assigning originalTz directly, which writes the string "undefined" when
originalTz was unset; modify the afterEach in
meme-calendar.helpers.timezone.test.ts to check originalTz: if it is undefined
delete process.env.TZ, otherwise set process.env.TZ = originalTz, using the
existing afterEach and originalTz identifiers to locate the change.

In `@components/header/header-search/HeaderSearchModal.tsx`:
- Around line 161-172: The plural-singular logic in HeaderSearchModal's token
normalization over-stems by treating any token ending with "ses" as removable;
update the condition in the function that checks token suffixes (the branch that
currently tests token.endsWith("ses")) to a narrower match such as
token.endsWith("sses") so words like "messages" or "cases" are not truncated
incorrectly, leaving the general token.endsWith("s") && !token.endsWith("ss")
fallback to remove simple trailing "s" cases.

In `@components/meme-calendar/meme-calendar.helpers.tsx`:
- Around line 616-623: The month formatting in formatUtcMonth currently calls
d.toLocaleString(undefined, ...) which uses the runtime default locale and can
cause SSR/CSR hydration mismatches; update the function so the toLocaleString
call uses an explicit locale (e.g., 'en-US') or add an optional locale parameter
defaulting to a fixed locale, ensuring the call to d.toLocaleString(...) passes
that explicit locale along with month/style and timeZone: 'UTC' (change inside
function formatUtcMonth to remove undefined and use the explicit locale or
param).

In `@contexts/TitleContext.tsx`:
- Around line 123-126: The current branch only resets the title and waveData
when a wave id disappears; change it to also reset when the wave id changes by
comparing the previous and current wave ids (not just their truthiness). In the
block that uses previousWaveInUrl and currentWaveInUrl, add a condition that
checks previousWaveId !== currentWaveId (derived from the query param used to
build previousWaveInUrl/currentWaveInUrl) and, when they differ, call
setTitle(getDefaultTitleForRoute(pathname)) and setWaveData(null) (same actions
as the disappearance case) so the old wave title is cleared whenever the active
wave id swaps. Ensure you reference the existing variables previousWaveInUrl,
currentWaveInUrl, previousWaveId/currentWaveId, setTitle, setWaveData,
getDefaultTitleForRoute, and pathname when applying the change.

---

Nitpick comments:
In
`@__tests__/components/brain/notifications/drop-reacted/NotificationDropReactedGroup.test.tsx`:
- Around line 102-124: The test currently returns a mock profile object cast
with "as never", which hides missing fields from the ApiProfileMin type; replace
this with a minimal, correctly typed mock factory (e.g., createMockProfile) that
returns ApiProfileMin and accepts overrides (Partial<ApiProfileMin> & { handle:
string }), populate required fields like id, handle, pfp, banner1_color,
banner2_color, cic, rep, tdh, tdh_rate, xtdh, xtdh_rate, level, primary_address,
subscribed_actions, and spread overrides; then use createMockProfile(...) in
place of the object and remove the "as never" cast so TypeScript will surface
any missing properties in functions/components that consume the mock (refer to
the returned object in this test and to ApiProfileMin).

In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 42-44: The three fields in NotificationDropReactedGroup mapping
use mixed fallback operators—handle uses nullish coalescing (preferred.handle ??
fallback.handle) while pfp and primary_address use logical OR (preferred.pfp ||
fallback.pfp, preferred.primary_address || fallback.primary_address)—so decide
whether empty strings should be treated as valid values; either switch pfp and
primary_address to nullish coalescing to match handle (preferred.pfp ??
fallback.pfp, preferred.primary_address ?? fallback.primary_address) or keep the
current operators but add a concise comment above these lines explaining why
handle preserves empty strings while pfp/primary_address fall back on falsy
values.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 60-62: The loop currently skips notifications when
getIdentityKey(n.related_identity) returns an empty string which silently drops
valid reactions; change the behavior in NotificationDropReactedGroup by
capturing the result of getIdentityKey for each notification (the const key =
getIdentityKey(n.related_identity) inside the for (const n of notifications)
loop) and if it is empty, use a deterministic fallback key (for example
"unknown-identity" or fallback to n.related_identity.profile?.handle ||
n.related_identity.id) and emit a console.warn or use the component logger to
record the missing key before grouping; ensure the rest of the grouping logic
uses this fallback rather than continuing the loop so notifications are not
lost.

In `@components/header/header-search/HeaderSearchModal.tsx`:
- Around line 333-351: The current matcher only tests each candidate field
independently (using hasCanonicalPageTokenMatch and
hasCanonicalPageTokenPrefixMatch over normalizedTitle, normalizedHref,
normalizedBreadcrumbs, normalizedSearchTerms), so queries spanning fields (e.g.,
"metrics health") miss matches; fix this by building and passing extra composite
searchable strings (e.g., join normalizedBreadcrumbs + normalizedTitle into
"network metrics health" and also shorter combinations like "metrics health")
into the same array you pass to the matcher and ensure the identical composite
list is produced and reused by getPageMatchPriority() so matching and ranking
remain aligned (update the construction logic where
normalizedTitle/normalizedBreadcrumbs/normalizedSearchTerms are assembled and
reference that composite-list in both the matcher call and
getPageMatchPriority).
- Around line 272-309: Add an explicit exact-href check so exact full-path
queries win before breadcrumb/token fallbacks: inside the checks array in
getPageMatchPriority (where normalizedTitle, hrefValues, hrefSegments,
normalizedQuery etc. are in scope), insert normalizedHref === normalizedQuery as
a high-priority entry (for example immediately after normalizedTitle ===
normalizedQuery) so an exact match on normalizedHref is found before any
breadcrumb/token-based checks or substring fallbacks.

---

Nitpick comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 26-33: getIdentityKey currently uses nullish coalescing
(profile.id ?? profile.handle ?? profile.primary_address ?? `unknown-profile`)
which will return empty strings as valid keys and can cause incorrect grouping
for ApiProfileMin entries with id === ""; change the logic in getIdentityKey to
treat empty strings as missing (e.g., use falsy checks or || instead of ??, or
explicitly check profile.id.trim() === "" before falling back) so that
handle/primary_address/`unknown-profile` are used when id is an empty string.
- Around line 193-197: The displayName assignment includes an unnecessary
null/undefined check and String() conversion for profile.id even though
ApiProfileMin defines id as a required string; replace the ternary block with a
simple fallback: use profile.handle ?? profile.id (remove the (profile.id ===
null || profile.id === undefined ? undefined : String(profile.id)) logic) so
displayName is either profile.handle or profile.id directly.

In `@contexts/TitleContext.tsx`:
- Around line 108-109: Remove the redundant aliases currentWaveId and
previousWaveId in TitleContext.tsx and inline currentWaveInUrl and
previousWaveInUrl directly where those aliases are used (e.g., in the
conditional checks around the currentWave/previousWave logic and the block
referenced near lines 125-128). Update any expressions or conditions that
reference currentWaveId/previousWaveId to use currentWaveInUrl/previousWaveInUrl
instead and delete the now-unused const declarations to reduce cognitive
overhead and unused variables.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 188-203: The single-reactor rendering path must validate
singleReactor.handle the same way the multi-reactor path does: before passing
singleReactor to NotificationHeader and NotificationsFollowBtn, check
singleReactor.handle and use profile.handle ? `/${profile.handle}` : undefined
(or fall back to rendering the multi-reactor layout) so you don't pass "/null"
or malformed hrefs like "identities//subscriptions"; update the
NotificationDropReactedGroup single-reactor branch to perform this guard and use
the validated/normalized handle value when constructing NotificationHeader and
NotificationsFollowBtn props.

In `@components/header/header-search/HeaderSearchModal.tsx`:
- Around line 301-338: pageMatchesQuery currently performs href substring checks
too late, so path-like partial queries (e.g., "/network/he") can lose to
token-based title matches; update the checks array inside pageMatchesQuery to
move full-href prefix and substring tests (e.g.,
normalizedHref.startsWith(normalizedQuery) and
normalizedHref.includes(normalizedQuery) or similar checks against
hrefValues/hrefSegments) before any token-based fallbacks (functions like
hasCanonicalPageTokenMatch, hasCanonicalPageTokenPrefixMatch,
hasExactCanonicalPageTokenMatch), and only run these full-href checks for
path-like queries (detect via normalizedQuery containing "/" or starting with
"/") so we prioritize direct path matches before token-based ranking.

---

Nitpick comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 46-59: mergeProfiles currently uses the nullish coalescing
operator for handle (preferred.handle ?? fallback.handle) which preserves empty
strings and leads to malformed links and API calls downstream (e.g.,
NotificationHeader and NotificationsFollowBtn); change the logic in
mergeProfiles to treat empty strings as missing by using a truthy check
(preferred.handle || fallback.handle) or a helper like getNonEmptyIdentityValue
for handle so empty "" falls back to fallback.handle, keeping pfp and
primary_address behavior consistent with handle.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 74-78: getIdentityKey/identityKey currently returns a single
preferred key which can split the same person across buckets; modify the
grouping logic in NotificationDropReactedGroup (where identityKey and key are
computed) to first attempt to match an existing byUser entry by any known alias
(n.related_identity.id, n.related_identity.handle,
n.related_identity.primary_address) before creating a new key; if any alias
matches an existing bucket use that bucket's key, otherwise fall back to the
existing identityKey/`unknown-identity-${n.id}` behavior so identical reactors
are grouped even when different fields are populated.
- Around line 96-106: The merge currently discards previously accumulated
profile data when folding an older notification: in the block that computes
isNewer, latest, fallbackIdentity and calls byUser.set, ensure you preserve
existing.identity when n is older than existing.latest by using
existing.identity (not raw existing.related_identity) as one of the inputs to
mergeProfiles; i.e., when isNewer is false set identity =
mergeProfiles(existing.identity, n.related_identity) (and when true keep
mergeProfiles(latest.related_identity, existing.identity)) so the accumulated
handle/pfp from existing.identity is retained before calling byUser.set.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 258-270: Normalize profile.handle once using
getNonEmptyIdentityValue and use that normalized value when building href,
displayName, title, and fallback in NotificationDropReactedGroup (instead of
using profile.handle directly); compute const normalizedHandle =
getNonEmptyIdentityValue(profile.handle) (or similar) and then set href =
normalizedHandle ? `/${normalizedHandle}` : undefined, displayName =
normalizedHandle ?? profile.id, title = displayName || undefined, and fallback =
normalizedHandle?.slice(0,2).toUpperCase() ?? "?" so empty or whitespace-only
handles no longer produce invalid hrefs or empty avatar/tooltips.

---

Duplicate comments:
In
`@components/brain/notifications/drop-reacted/NotificationDropReactedGroup.tsx`:
- Around line 88-94: When assigning a bucket for a reactor you currently only
pick the first matching alias (matchingKey) and repoint aliasToKey, which leaves
other pre-existing byUser buckets unmerged and causes duplicate renders;
instead, collect all aliases from getIdentityAliases(n.related_identity) that
exist in aliasToKey, determine one canonical key (e.g., fallbackKey or the first
existing key), then merge every other bucket's contents from byUser into that
canonical byUser entry, update aliasToKey for each merged alias to point to the
canonical key, and delete the now-empty/duplicate byUser entries so all aliases
fold into a single bucket.